The present invention relates to computer software, and more specifically to client-server computer software.
Where a single repository of data is shared by many users, a client-server architecture may be adopted. Referring now to FIG. 1, four computers 110, 112, 114, 116 arranged using a client-server architecture are illustrated. In a client-server architecture, a server 110 is used to access a data repository storage device 102 that stores the data that is shared among the clients 112, 114, 116. Clients 112, 114, 116 can request the data from the server 110, process data, provide data to the server 110 and change data stored in the storage device 102 attached to the server 110. Users of the client-server system 100 use a client 112, 114, 116 to communicate with the server 110 to access the shared data stored in the storage device 102. Clients 112, 114, 116 do not have direct access to the data in the storage device 102, but may request that the server 110 perform actions such as performing queries, or adding to or changing the data stored in the storage device 102.
Each client 112, 114, 116 is coupled to the server 110 by a connection 122, 124, 126 between the clients 112, 114, 116 and the server 110. Each connection 122, 124, 126 may be physically separate as shown in FIG. 1, or may be shared using a local area network, or LAN. Ports 142, 144, 146 in each of the clients 112, 114, 116 and associated cabling provide the OSI layers 1-2 connectivity between the ports 132, 134, 136 of the server 110. If the server 110 will communicate with each client 112, 114, 116 over a LAN, a single LAN interface port may physically replace ports 132, 134, 136, and ports 132, 134, 136 are treated as logical ports.
As the user of each client 112, 114, 116 performs work, the client 112, 114, 116 will send commands to the server 110, and some of the commands will cause the server 110 to send data to the requesting client 112, 114, 116. Each command that is sent to the server 110 requires resources from the server 110 to process the command. Commands that request data not only require the server 110 to process the command, but also to obtain the data from the data storage 102 and transmit it to the requesting client.
A conventional client 112, 114, 116 obtains data from the server using a request, such as a conventional query execute command. A conventional query execute command describes the data to be retrieved using a user command such as the following command, which selects the first, last, sex and department fields from an employee table for all employees having a department field equal to xe2x80x9cENGINEERINGxe2x80x9d:
xe2x80x83select emp_first, emp_last, emp_sex, emp_dept
from_employee
where emp_dept=xe2x80x98ENGINEERINGxe2x80x99xe2x80x83xe2x80x83(Query 1)
The client 112, 114 or 116 formats the query execute command to include the select command above in a format required by the server and passes it to the server 110 in the form of a query execute command. The server executes the query and sets up pointers to the results in a storage area of the server 110 such as memory or hard disk. In the conventional Oracle 7 product, this area is known as an evaluation tree, and the evaluation tree is pointed to by a cursor, described below. The use of an evaluation tree and a cursor allow the query result to be rapidly retrieved from the storage device 102 a portion of the table at a time.
The data pointed to by the cursor is logically arranged as a table, with data related to each of the records described by the query corresponding to a row, and each of the fields described by the query corresponding to a column. Referring now to FIG. 2, sample results of the execute command including the select statement shown in Query 1 above are shown in table 210, with columns 212, 214, 216, 218 corresponding to the first and last names, sex and department, respectively, and rows 220-230 corresponding to individual records described by the query. The data in table 210 need not be physically arranged as shown, but may be referred to and transmitted logically as shown.
Referring now to FIGS. 1 and 2, commands sent from the client 112, 114, 116 to the server 110 direct the server 110 to transmit to the client 112, 114 or 116 some or all of the table result 210 pointed to by the cursor. Using the query execute command, the client 112, 114, 116 can direct the server 110 to not only execute the query, but also to provide a portion of the results to the requesting client 112, 114, or 116. Additional portions of the result are requested by the client 112, 114 or 116 using a xe2x80x9cfetchxe2x80x9d command, which causes the server 110 to fetch a specified amount of data from the storage device 102 and transmit it to the requesting client 112, 114, 116.
Using this execute-fetch approach, the client 112, 114, 116 can develop the query, have it executed by the server 110, yet accept only a desired amount of the results of the query at a time. If the initial portion of the results of the query are not sufficient to the user of the client 112, 114, 116, the user may not wish to see the remainder of the query results, saving transmission to the client 112, 114, 116 of the remainder of the unwanted result. Alternatively, if the user wishes to see or process additional data from the query result, the client 112, 114, 116 can request it using one or more subsequent fetch commands, with each fetch command retrieving a specified number of rows 220-230 of the table 210.
The ability to receive only a portion of the table result saves the server 110 the overhead of passing the entire table result for a query that the user may discard. Another benefit to the executexe2x80x94fetch command arrangement is that query table results which are larger than the storage capacity of the client 112, 114, 116 may be processed by the client a portion at a time.
Because the details of the execute and fetch commands may be cumbersome to a user, application software in each client 112, 114, 116 handles building the execute and fetch commands in response to indications made by the user to the user interface of the application software in the client 112, 114, 116. It is possible for the application software to manage the fetching process in a manner that is transparent to the user. The user believes that all of the table result is available in the client 112, 114, 116 and is unaware of the actual location of the query table result being displayed.
While the executexe2x80x94fetch system provides some of the benefits described above to the clients 112, 114, 116, it can impose significant drawbacks on the server 110. The overhead required for the server 110 to perform each of the many fetches which may be required can be significant. The retrieval of the result from the storage device 102, which may be one or more conventional hard disks, requires heads to be repositioned to the proper sector, a relatively time consuming task. While disk caching systems can alleviate some of the head repositioning delay, if hundreds of users will access data relatively infrequently, the benefits from disk caching may be reduced unless the cache is relatively large, increasing its cost. Furthermore, even with a caching mechanism, the processor in the server 110 must still receive and process the fetch request for data. This processing can be substantial. For example, the processing can require the operating system to schedule the process that needs to process the call and this overhead can be quite high. Then, one or more subroutines must be called, which slow the processors in the server 110 from servicing the other clients 112, 114, 116 which share the server 110. Thus, receiving and processing fetch requests can require substantial processing overhead and this overhead may substantially exceed the amount of processing power required to fetch the data requested. If many small fetch requests are received, the response time of the server can be degraded.
In addition, in a client server system that allows session switching similar to that described in application Ser. No. 08,872,529, U.S. Pat. No. 8,243,751 or Ser. No. 08/873,057, U.S. Pat. No. 6,088,778, the overhead required to process a fetch command is further increased in order to switch the session. It is therefore desirable to reduce the number of commands that request data from the server 110.
Error and status information about the data transmitted from the servers 110 to the clients 112, 114, 116 is generated by the server 110 to describe the data and any error conditions that may occur. It is desirable to provide this information to the clients 112, 114,116 without requiring processing resources of the server 110
In addition, the cursor and evaluation tree may occupy memory in the server 110 that is not released until the server 110 has transmitted to the client 112, 114, 116 the entire table result requested by such client 112, 114, 116 or the user of the client 112, 114, 116 otherwise directs the server to release the area of memory for the cursor, for example by logging out or by indicating that no more results are desired. If the only mechanism the server 110 has to identify that the entire table result has been returned is to identify when a request is received to return to the client 112, 114, 116 a row past the end of the table 210, it is possible that such a request may never be made, causing the cursor to occupy memory in the server 110 well past the time the user will use the cursor and evaluation tree, until the user logs out or otherwise directs the server to discard the cursor and evaluation tree.
The use of memory in the server 110 for the cursor and evaluation tree can prevent the memory from being used to support other users or potential users of the server 110, slowing the response time of the server 110 or preventing its use by other potential users. Thus it is desirable to cause the memory reserved for the cursor and evaluation tree to be released as quickly as possible.
In accordance with the present invention, a server can provide more data than is requested by the application software in the client. The additional data may be stored by the client or other device external to the server in a storage device that may not be fully utilized. The additional data is made available to the client for use in place of a subsequent fetch command by the client to the server, thereby reducing the number of fetch commands sent over the network to the server if a subsequent fetch command may instead be fulfilled from the additional data previously sent, reducing network traffic and the need for the server to process commands as xe2x80x9croundtripsxe2x80x9d. Because the server does not have to process as many commands from each client, the same configuration server can perform substantially more work. Because the server provides more data than requested by the application software in the client, subsequent data requests are fulfilled sooner and the server memory used for the cursor and evaluation tree is thereby released sooner for use by other server functions. Because error and status information about the result may be generated by the client, server processing resources required are reduced and network traffic between the server and clients is reduced. The present invention can therefore significantly improve response time in a client-server or other similar architecture.
For example, many personal computers operate as a client in a client-server system, with large amounts of memory that may only be partially utilized by the operating system and application software running on the personal computer. This memory can be used as described herein to enhance the performance of the client-server system without any increase in cost. Similarly, processing resources in the client may not otherwise be fully utilized, and these processing resources can offload some of the processing that would otherwise be performed by the server.